Large, complex projects typically produce items such as designs, components, tests, and reports. These items are supplied by one party and received by another. Variables such as request dates, due dates, costs, and specifications are associated with each item. Each variable must be coordinated and scheduled between multiple sets of suppliers and receivers to prevent cost overruns and delays in the project's completion.
Both the variables in the project and the complexity of organizing these variables increase with the project's size. The project, in turn, becomes more difficult to manage.
Manufacturing projects for one-of-a-kind items (e.g., a NASA spacecraft) are particularly difficult to manage. These projects typically include larger numbers of supplied and received items than projects for manufacturing similar, well-established items (e.g., automobiles). A NASA spacecraft, for example, includes a large number of specialty parts which are not commercially available. These parts must therefore be fabricated in-house or sub-contracted to outside firms. Such parts often require specialized testing and detailed performance reports. This introduces more supplied and received items, and thus even more variables, into the project.
Control methods are implemented by manufacturing firms to organize and facilitate completion of the project. A standard control method features a hierarchy of managers (such as Project, Area, and Technical Managers), each of whom supervise a group of employees responsible for completion of a portion of the project. During day-to-day operations, individual employees supply, receive, and/or deliver particular items of the project; the status of each item then reported to the supervising manager. Information is then collected, tabulated, and evaluated to manage the project.
Several problems exist with conventional methods for project management. The inventor recognized that these methods lack a structured methodology for defining, recording, and processing the multiple variables that are associated with the project. Instead, information is typically communicated from employees to supervisors, and then through the management chain. Eventually, the information is somehow used to determine the project's status.
Standard project management requires the information to be communicated from one party to another. Good communication between suppliers and receivers is needed for efficient project management. The inventor recognized significant advantages from recording information directly in a centralized database. Otherwise, all employees cannot receive updated, real-time information about the status of the project. A lack of information can result in mis-communications between suppliers and receivers. These factors become even more pronounced as the size and number of the project's variables are increased.
Applicants have developed a schedule-control method for managing and controlling projects to overcome these and other limitations. The method is implemented using an electronic user interface, relational database, and computational component. Each of these components work together to process input data in a special format that is defined herein as a "receivable/deliverable" (or "rec/del") format. Using the rec/del format, the method breaks down the project into a series of smaller components, referred to herein as "tasks". Each task involves a "contract" between a supplier and a receiver. The contract results in the production of a "product". Users can enter and access up-to-the-minute input data concerning a particular product or task from the rec/del system.
The schedule-control method includes several steps for receiving, processing, analyzing, computing and sending information for monitoring the status of the project. In a first step, suppliers or receivers enter the first set of input data to the method to identify the input and output products of their particular task. The first set of input data processed by the computer upon receipt are "bids". Bids are sent by suppliers and receivers over an electronic user interface and stored in the relational database of a computer.
The electronic user interface is either e-mail or a user-interface computer program. Both of these interfaces can be implemented on conventional personal computers connected and distributed over a local-area network (LAN) or over a wide-area network such as the internet. Each supplier and receiver must have access to a computer connected and distributed over the local-area or wide-area network. The combination of these features allows users to quickly and easily supply input data and access output data.
The input data within a bid identify a particular product by: 1) naming the product; 2) associating a receiver's identification number (i.e., an account identification code) with the product; 3) associating a supplier's identification number with the product; 4) associating the receiver's required delivery date with the product; and, 5) associating the supplier's available delivery date with the product. These input data are provided for each product in the project. A contract is formed when both the supplier and receiver agree to the criteria used to define the product.
The input data within the bid are then analyzed by the computational component to determine the "state" of each product in the project. For example, the states of a product include "reconciled", "date not agreed", "product not agreed", or "no impact". If one party changes one of the criteria during the course of the project, the product's state is no longer in agreement. This change must be reviewed and accepted by the other party to complete a new contract.
Each state includes different "comments" for describing the particular product. For example, a comment such as "completed" can be entered under the "reconciled" state; a comment such as "no deliverable" can be entered under the "product not agreed" state. The comments are sent as a first set of output data to the appropriate suppliers and receivers. These users can then negotiate and update the product's state by responding with new input data. For example, work performed or further negotiation may drive the product's state from "date not agreed" to "reconciled".
The negotiating process is repeated, and work on the contract is carried out, until the state is reconciled and the product is finished. The receiver ultimately determines when the product delivery date has been successfully completed.
The status of the entire project is determined by collectively processing the various states for each individual product or task. For instance, the states can be summed together. Once determined, the actual status of the project can be packaged as a second set of output data. Data are computed to generate real-time reports so that the status of the project can be determined at any particular time. These data can be accessed via the electronic user interface by the various suppliers and receivers involved with the project.
The second set of output data can be in the form of plots, charts (e. g. GANTT charts), and reports. These data can track a particular product or the entire project. In a preferred embodiment, the second set of output data is in the form of a plot comparing the project's actual status to its predicted status. Planning and performance reports serving as metrics for identifying problem areas can also be generated. Planning reports identify products where the delivery dates conflict with those requested by the receiver, the supplier is missing, or there is no receiver. Performance reports compare the actual and planned quantities of individual products over time.
All levels of the project's suppliers and receivers--ranging from high-level Project Managers to Technical Managers to Engineers--can use the schedule-control method to control and iterate their portion of the project. Users access a timely, robust set of processed data. Suppliers and receivers can predict future time periods which may require changes in the project's structure or adjustments in the deployment of the project's resources. Ultimately, the schedule-control method facilitates successful completion of the project.
The above-described techniques have many advantages when compared to conventional organizational methods. In particular, the rec/del format facilitates efficient communication between the suppliers and receivers of a particular product. Data are supplied and received by those directly involved with a particular area of the project. Input data in the rec/del format can be modified independently without modifying the schedule of the entire project.
Distributing the control of the project over a group of users is also advantageous. Individual users can focus more resources on monitoring and controlling the flow of products within the project. Less time is spent monitoring a single product and conveying and distributing data concerning the product to supervising managers.
Distribution of control also alleviates some of the responsibilities of the project manager. Personnel dedicated exclusively to planning the project are unnecessary, as each individual user has direct control over his or her plans. In effect, the schedule-control method becomes the project's centralized control center which simultaneously facilitates decentralized decision making. This decreases the probability of cost overruns, and increases the probability that the project will be completed according to plan.
The method is particularly effective when used with large, complex, one-of-a-kind projects. Such projects typically involve large numbers of interactions between suppliers and receivers, and consequently have large degrees of uncertainty in their schedules. For example, the method can be used to effectively manage projects such as the construction of a NASA spacecraft.